BVNs are networks which transport high quality video from locations like sports stadiums to be delivered to end users, typically via terrestrial/satellite broadcast or cable. All major sports events, including the Olympics, football, golf, horse racing, and the like, are carried over BVN networks.
BVNs are unique in terms of their high value, high bandwidth, multipoint, and reliability requirements because they transport high value streams, where dropping even a single video frame can cost millions of dollars. For example, a single black frame in the middle a Super Bowl Football advertisement will mean the advertiser does not pay the usual multi-million dollars for the advertisement slot. Additionally, fans (or users) will not pay the indulgent monthly subscriptions fees if the media (i.e., video and audio) regularly fails during game play. For these reasons, reliability is extremely important, and is the reason broadcasters spend millions of dollars on redundancy, failure protection solutions, and operators to react quickly to failures. However, The IP multicast networks regularly suffer link or node failures that results in packet loss, typically 50 ms, impacting video playback and costing broadcasters millions of dollars.
IP Multicast BVNs are networks which transport video, and are logically separated into two (2) sections: Contribution and Distribution. The contribution component is where high quality video is sourced from locations like sports stadium, of film studios, and delivered to a main studio or broadcast center. Then the video then undergoes various treatments, generally referred to as “production”, where the video is edited, mixed, has advertisements inserted, and other modifications. The video within contribution side is typically as high as quality as possible and reliability is very important, as an impact here will affect all consumers. Most the production phase, the video then needs to be distributed to the consumers of the video. Typically, the video is typically significantly compressed to a much lower quality to allow it to be transmitted over the lower bandwidth delivery services.
IP Multicast Networks may utilize special purpose built wide area networks (WANs). The WANs that the IP multicast networks are run on also have dedicated guaranteed bandwidth so that bandwidth is guaranteed and not shared, unlike the Internet, such complex congestion control mechanisms are not necessary, although care is still required to avoid unnecessary retransmission and/or acknowledgement (ACK) and/or negative acknowledgement (NACK) implosion. WANs also have over-provisioned bandwidth to avoid the possibility of network congestion they have circuits that are over provisioned.
Further, the WANs have In-order delivery (fixed size packets). Typically, encoding devices generating the packet streams insert MPEG null packets resulting in fixed size packets of 1370 bytes. While this means that packet switch/route handling times are fixed, and packets arrive in order, it wastes bandwidth.
WANs also have video transport protocol simplicity (simple RTP encapsulation only), and consequently, the video encoders typically use very simplistic methods to transport the video over IP. They encapsulate the MPEG packets in Real-time Transport Protocol (RTP), but do not implement Real Time Control Protocol (RTCP), or Session Description Protocol (SDP). Furthermore, they even ignore parts of the RTP header, ignoring synchronization source (SSRC) identifier, and also ignore the contributing source (CSRC) identifiers. Streams are simply identified by the source-IP and multicast-group address, typically referred to a “S,G”, and then in the case of multi-program-transport-streams (MPTS) the Packet Identifier (PID), which can lead to reliability issues.
WANs further comprise redundant circuits that are always deployed, which essentially means there is twice (2×) as much bandwidth as is strictly necessary, leading to higher cost since network devices are always duplicated.
Lastly, in WANs, high value streams are duplicated across the network to protect against any failure within the entire video chain. Protection is this case is typically automatic (sometimes manual) switching to the second stream if black is detected. In the automated case, the RTP headers are used to detect loss, and insert from the secondary stream. This is unduly complicated and burdensome.
IP multicast networks over these WANs are carefully designed to minimize bandwidth consumption, such that the shortest distribution tree is built from the source to all the receivers. At a high level, the network routers distribute network topology information with one another, select the best path, and then maintain regular heartbeat communication with each other via hello/reply messages. If/when the hello/reply messages detect a failure, a new best path needs to be selected and then used, which takes time. While there has been a large amount of effort to improve the failure detection time, reduce the time taken to switch to the next best path, in all cases there is a brief moment of packet loss.
Broadcasters have attempted to work around these issues by deploying high reliability devices, minimized timers, and Forward Error Correction (FEC) systems such as SDH/SONET Automatic Protection Switching (APS) Rapid Spanning Tree Protocol (RSTP), SDH/SONET and the like, but these are limited to between 50 ms and 2000 ms. In these systems on BVN, packet loss may occur.
These devices and work-arounds do not speak to the heart of the problem of packet loss, and also, these past ad hoc approaches for remedying some of the issues mentioned above are platform-specific, expensive, time consuming, and most importantly, are ineffective in some circumstances.
Packet loss in typical shared/Internet networks, is relatively complex, where we can typically see intermittent losses and out of order packets. The packet loss on BVNs is by comparison is very simple, as all packets arrive in the correct order, except during a failure when none of the packets arrive, and then after recovery all the packets continue arriving in order. The failure causes all the packets in a continuous sequence of dropped packets until the network recovers. This means that unlike the reliable TCP protocol, which uses positive (sometime selective) acknowledgement, with relatively complex retransmission methods, within BVNs retransmission can be greatly simplified.
As an example, assuming a network with four nodes: If the network between node 1 and node 2 fails, then downstream nodes 2, 3, 4 all miss the same packets. If the network between node 2 and node 3 fails, then downstream nodes 3 and 4 all miss the same packets.
For example, An Error-Control Scheme for a Multicast Protocol Based on Round-Trip Time Calculations by Daniel Bauer et al describes a system and method in which lost packets are detected using sequence numbers. Each packet contains a sequence number. If a receiver detects a gap in received sequence numbers, it requests lost packets from the sender or possibly from other receivers by sending a retransmission request (RRQ). If the RRQ is multicast to the group, other receivers that experienced an identical packet loss will recognize it and suppress their RRQ. However, this approach lacks in the feature combining the parallel timing, using the standard RTP headers, negative NACK, and NACKing based on early detection of loss by looking at the timing of when packets should arrive.
Further, Real-Time Multicast with Scalable Reliability by Patrick C. K. Wu et al describes a protocol for real-time multicast application scaled MSR (Multicast with Scalable Reliability) in which a receiver detects a loss when a timer expires or the sequence numbers of two successive received packets are not continuous. However, system assumes losses of single packets, when practically speaking, multiple packets may be lost.
U.S. Pat. No. 9,270,475 to Maxemchuk et al. describes a system and method for the repair of IP multicast sessions using a repair server that polls multiple transmit servers to accumulate as many of the packets missing from the multicast session as possible. In this system, retransmitted packets in the bypass session are forwarded to circumvent at least some of the congested, multicast enabled routers in the long-haul portion, accomplished by transmitting the missing packets over a separate dial-up network or a private virtual network from the retransmit servers to the repair server. However, the repair server transmits via unicast, not multicast, and is thus inoperable in certain situations.
There is a cost associated with these protection devices and methods. Even if they cut times down, to 50 ms, or a twentieth ( 1/20th) of a second, it still means many dropped video packets, leading to the inability to successfully reassemble an MPEG transport stream, resulting a failure to decode video and ultimately black video frames. Even with advanced FEC algorithms, like RaptorQ for example, that even at data rates as low as 7 Mb/s, there is loss of hundreds of packets, such that repair is impossible. Over time, as video quality improves, and the data rates go up, the number of lost packets will obviously increase.
Accordingly, there is a need for a system and method for improving reliability of media delivery on BVNs that use internet protocol (IP) multicast, while being easily scalable and inexpensive and virtually error-free.
Unless otherwise indicated, illustrations in the figures are not necessarily drawn to scale.